The concept of pre-configured or purpose built sensor devices are common. Also pre-configuration of smartphone sensors in applications is seen today. One example of how such a configuration is performed by downloading an application to a smartphone that is thus configured to register bumps in the road by usage of the accelerometer (for bump detection) and the GPS for geo-location. The sensor data is then reported to road maintainers. This is an example of a pre-configured sensor device, that is configured out-of-context, e.g. during application install at home. Another example of out-of-context configuration is triggering pre-defined events when a known wireless/cellular network is within range or a pre-defined geo-location area is reached. The events and the corresponding operation are predefined and only the detection of the event triggers the execution, but the operation is, as such, defined out-of-context.
The main problem is that a general sensor device can be used for many different purposes and out-of-context instructions will be huge if they should cover all possible contexts. Furthermore, it is not possible to handle new contexts without bringing the device in for an out-of-context update. Another problem is time varying context awareness which is impossible to support through an out-of-context configuration.
For example, assume a general sensor included in a container that needs to be kept cold and being transported by a truck, say. During transportation it might be important to keep track of the goods (GPS) as well as keep track on the temperature with regular intervals. On the other side, once the device comes to a warehouse there is no need for GPS reporting (not so often at least) and it may be a place where the temperature is under control so there might not be a need to perform temperature measurements too often.
In prior art solutions a general sensor may be configured to report a. position and a temperature every minute, what so ever circumstances, draining battery for the sensor. While, in practice, it may suffice with a reporting every hour or so once the sensor is in a warehouse. The general sensor according to the prior art solutions would thus draw an unnecessary amount of power, both for sensing and for reporting the measurements.
Furthermore, the reporting itself may imply costs (roaming etc), and therefore the reporting may incur higher operating costs than actually needed.
Therefore, there is a need for method and apparatus for remote instruction of general sensor device for specific actions requested in a specific context.